-
-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#492.1
attempt
#717
#492.1
attempt
#717
Conversation
Hey! Thanks for looking into this and for the nice PR :o ! I haven't looked at the code yet, but from a high-level "requirements" perspective:
|
@KtorZ I kinda like what's going on here with automatically getting the latest tag, I think that's a good work flow. |
I am not sure. That's an implicit behavior which may lead to confusion. If you've never asked to install version 1.8.0 then why would you tie your app to that version. Then people might get confused because they can't use something they see in the doc but that's not yet released. Plus, many library maintainers are often very lenient on the tagging and only really tag new versions when asked. Hence the latest tag may be months behind the main branch. So, I believe the only raisonnable behavior to adopt when no version is specified is to stick with the latest. The true latest. Any other implicit choice made on behalf of the user may lead to confusion. |
Hm I see and I guess these assumptions start to change slightly when we finally introduce a proper package registry. There's definitely a lot that can be done with git based package management considering Go has a good setup now but I think it's also awkward for the reasons you mentioned. |
Hey I didn't mean to re-push this (forgot to create a sub-branch -_-), I wanted to discuss first.
The reason was, by setting the version to Most repo would have I tried to set the default version to the last commit of the default branch, but it's weird looking,
might be better to tell the user to manually select the commit hash themselves. |
An attempt to do #492 point 1:
--version
option onaiken add
could be made optional; when not provided, the dependency will be added considering only the default branchaiken add <PACKAGES>
:aiken add
:When no
--version
provided, it will try to get the package version with the following order:↳
LatestRelease
- if no non pre-release version, then ↴↳
Releases[0]
- if no release available, then ↴↳
MainBranch
- if for some reason no branch namedmaster
ormain
, then ↴↳
Branches[0]
- should be available, but for the sake of completeness ↴↳
Tags[0]
- if everything fails, then version will bemain
Since
packages upgrade
command calls theadd
command withoverwrite: true
, soaiken packages upgrade <PACKAGE>
:aiken packages upgrade
:Note
: Free Github API has rate limit, so it's still preferable to provide--version
for now